> Well, that brought out some friendly debate, to state the obvious. Part of the group posted words of encouragement, noting that we need to support those programming for the environment. The other half of the camp echoed the words of Patrick Leung, who expressed concern that there are many programmers in the arena that are doing the same thing separately. He encouraged programmers to consolidate features and code bases to arrive at robust full-featured programs instead of fragile bare-bones applications that single programmers can't support. ACE, Craig Bruce's UNIX-like OS detailed in earlier C=Hacking issues, was brought up by some, who asked that programmers heed Leung's advice and build modules for the already supported ACE environment.
I, of course, support the idea of other people building more applications for the ACE environment. I also support the idea of using ACE applications with other operating systems. ACE was built on the idea of providing a well-defined Application-Program Interface (API), and any alternative OS that can emulate the ACE interface (using a "middle-ware" layer of software) can run all of the existing ACE applications. Thus, a new operating system can have a base of (a few) high-quality programs available instantly (high-enough quality that even I use them). Admittedly, I have to update the documentation on the ACE API, since it changed in Release #15, but the basic functionality will always be the same.
In addition, I also support the idea of other people using ACE code inside of their own operating systems. Why re-invent the wheel? Especially useful may be the dynamic-memory stuff and some device drivers. ACE is Public Domain software, so you can do with it whatever you please.
>@(A): The "More Power" Swiftlink: Ever striving to squeeze the most performance out of his C128 system, Craig Bruce modified his Swiftlink and lived to tell about it in the newsgroup.. Basically, after researching the data sheets for the 6551 ACIA IC used in the SL, Craig noted that Dr. Evil Labs (the original creators of the SL) had used a double speed crystal to up the 19,200 bps maximum in the ACIA to 38,400 bps. The IC claims that any baud rate up to 125,000bps can be achieved with the IC, given the correct crystal frequency. Well, another feature of the 6551 is to use the crystal frequency/16 as the bps rate, which is 230,400 bps or the stock crystal. Too fast for the IC. However, by replacing the crystal ( a 3.6864 MHz unit) with a 1.8432 MHz unit, the 1/16 speed becomes 115,200. That speed, less than 125,000 bps, is the standard top frequency for IBM UARTs and is supported by most newer modems. Craig verified that his 2MHz 128 can keep up with the extra data that his modofoed SL allows him to receive, but not always. he claims that every once in a while, the systm gets choked up and crashes, so he is working on solutions. Understandably, one will need very tight terminal program code to keep up with this speed, but it will fit nicely with the SuperCPU.
To update the story a little, ACE Release #15 supports the hacked swiftlink and works flawlessly at 115.2kbps (I'm using it right now). It required programming a bare-bones NMI handler and counting up the clock cycles by hand to be sure (and I am sure). Also, I use my hacked SwiftLink at 115.2kbps every day, and I have never had any hardware problems with it either.
> As with all things, there is a downside in that 19,200 becomes the next lower bps rate. 38,400 is gone forever. Craig speculated that perhaps a switch could be installed, but wasn't sure of the effects.
I haven't tried putting a switch, and I don't think that I will. 115.2kbps suits me fine.
-----------------------------
Internet Terminal Programs
From: mpython@vgernet.net (Monty Python)
Phil Porth (pdporth@freenet.calgary.ab.ca) wrote:
> Does anyone know offhand, what u/d protocols that ACE supports
Aceterm only supports 1 protocol. It is a custom u/dl protocol called FX, and it is great. It send files in chunks of data anywhere from 1k to around 15k. It is EXTREMELY fast when used with a ramlink. You will need to get the fx.c program and compile it on a UNIX Shell for it to work. That is also available at ccnga.uwaterloo.ca, and I believe it is under /cbm/os/unix; eitherway it is in the unix directory under the os dir.
I would definatley recommend this to anyone who wants to u/dl as fast as possible on a 64/128.
